IIHIHmWMlMlfill, 

US006601136B2 

(12) United States Patent ao Patent No.: us 6,601,136 B2 

Gunaseelan et al. (45) Date of Patent: Jul. 29, 2003 



(54) MEDIA SERVER SYSTEM AND PROCESS 
HAVING DEVICE INDEPENDENT NEAR- 
ONLINE STORAGE SUPPORT 

(75) Inventors: Lakshminarayanan Gunaseelan, 
Milpitas, CA (US); Eliahu Lauris, 
Sunnyvale, CA (US) 

(73) Assignee: Kasenna, Inc., Mountain View, CA 
(US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 10/037,756 

(22) Filed: Oct. 22, 2001 

(65) Prior Publication Data 

US 2002/0152364 Al Oct. 17, 2002 

Related U.S. Application Data 

(63) Continuation of application No. 09/183,877, filed on Oct. 
30, 1998, now abandoned. 

(51) Int. CI. 7 G06F 12/00 

(52) U.S. CI 711/112; 711/169; 709/231 

(58) Field of Search 711/112, 111, 114, 

711/169; 709/208, 213, 217, 219, 231 

(56) References Cited 

U.S. PATENT DOCUMENTS 

5,761,667 A * 6/1998 Koeppen 707/101 

OTHER PUBLICATIONS 

Crutcher et al., The Networked Video Jukebox, 1994 IEEE, 
pp. 105-120.* 

Eitel, backup and Storage Management in Distributed Het- 
erogeneous Environments, 1994 IEEE, pp. 124-126.* 



Wu et al, "On the Design of Stream Pumping Engines for 
Scalable Video-on-Demand Systmes", © 1997, IEEE, p. 
381-385.* 

Ludescher et al., file Storage management forTFTR Physics 
Data, 1992 IEEE, pp. 856-859.* 

Byrne, Evaluating jukebox performance, 1997 IEEE, pp. 
70-73.* 

Jun et al., Video Allocation Methods in a Multi-level Server 
for Large-scale VOD Services, 1998 IEEE, pp. 
1309-1318.* 

Ford et al., redundant Arrays of Independent Libraries 
(RAIL): A Tertiary Storage System, 1996 IEEE, pp. 
280-285.* 

Goodheart et al., The Magic Garden Explained, © 1994, p. 
40, 41, 357-360, 497, 498. 

* cited by examiner 

Primary Examiner — Do Hyun Yoo 

Assistant Examiner — Brian R. Peugh 

(74) Attorney, Agent, or Firm — Dorsey & Whitney LLP; R. 

Michael Ananian 



(57) 



ABSTRACT 



A media server system and process are disclosed that have 
device independent near-online storage support. A plurality 
of media assets are stored in online storage, and a plurality 
of media assets are stored on tertiary storage devices in 
tertiary storage to provide near-online storage. A media 
server, having access to the online storage and the tertiary 
siorage, receives a user request for a media asset. The media 
server then determines whether the requested media asset 
needs to be loaded from the tertiary storage. If so, the media 
server allocates space in the online storage for the requested 
media asset. A transfer process specific to the tertiary storage 
devices is then used to transfer content of the requested 
media asset to the online storage. 

14 Claims, 3 Drawing Sheets 
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MEDIA SERVER SYSTEM AND PROCESS 
HAVING DEVICE INDEPENDENT NEAR- 
ONLINE STORAGE SUPPORT 

This is a continuation of application Ser. No. 09/183,877 
filed Oct. 30, 1998, now abandoned. 

TECHNICAL FIELD OF THE INVENTION 

The present invention relates in general to the field of 
digital media and, more particularly, to a media server 
system and process having device independent near-online 
storage support. 

BACKGROUND OF THE INVENTION 

Digital media files are widely used to record a variety of 
media assets-for playback on computer systems. A decoder 
or player is a software or hardware component, such as a 
software application or hardware card, that receives digital 
media data and renders it for playback, for example, as a 
displayable image, playable audio or a combination of the 
two. One distribution method used for digital media files is 
a media server which can hold a large repository of media 
files. The media files can be streamed as digital packets 
across a network connection, such as a local area network, 
wide area network or the Internet, to client systems for 
playback. The media server usually divides the media files 
into data packets which are then delivered to the client 
system across the network connection. 

Such digital media streaming systems typically stream 
content from data stored on hard disk drives. However, in an 
installation with a very large number of digital media assets 
(e.g., government agencies, various studios, etc.), it may not 
be practical to have all of the desired asset content stored 
online on hard disk drives. Yet there remains a need to be 
able to stream any of the desired assets with a short latency. 
To address this problem, various near-online storage devices 
are available that provide tertiary storage for digital media 
assets. These devices typically provide permanent storage 
for media assets in storage devices such as CD-ROMs and 
magnetic tape devices. 

One significant problem that arises is that near-online 
storage devices can vary widely in terms of the mechanisms 
employed for the actual transfer of data. Further, there are 
variations in the interface provided for controlling the 
devices and the transfer of data and in the performance 
characteristics. Thus, it can be problematic for a digital 
media server system to provide support for the various 
possible types of near-online storage devices. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, a media server 
system and process are disclosed that have device indepen- 
dent near-online storage support and that provide advantages 
over conventional digital media server systems. 

According to one aspect of the present invention, a media 
server system and process have device independent near- 
online storage support. A plurality of media assets are stored 
in online storage, and a plurality of media assets are stored 
on tertiary storage devices in tertiary storage to provide 
near-online storage. A media server, having access to the 
online storage and the tertiary storage, receives a user 
request for a media asset. The media server then determines 
whether the requested media asset needs to be loaded from 
the tertiary storage. If so, the media server allocates space in 
the online storage for the requested media asset. A transfer 
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process specific to the tertiary storage devices is then used 
to transfer content of the requested media asset to the online 
storage 

A technical advantage of the present invention is ihc 
5 ability for a media server system to remain device indepen- 
dent with respect to near-online storage devices and be able 
to interface with such devices uniformly. At the same lime, 
the media server system has the ability to exploit unique 
performance enhancement opportunities of the near-online 
10 storage devices. 

It is another technical advantage that the media server 
system has the ability to accommodate unforeseen tcchno- 
logical innovations and to integrate with new forms of 
near-online storage devices. 

Other technical advantages should be readily apparent to 
one skilled in the art from the figures, description and 
claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 

A more complete understanding of the present invention 
and advantages thereof may be acquired by referring to the 
following description taken in conjunction with the accom- 
panying drawings, in which like reference numbers indicate 
25 like features, and wherein: 

FIG. 1 is a block diagram of one embodiment of a media 
server environment; 

FIG. 2 is a How chart of one embodiment of a process for 
3Q near-online storage support; 

FIG. 3 is a fiow diagram of one embodiment of allocating 
storage and asset finalization; 

FIG. 4 is a fiow diagram of one embodiment of allocating 
disk bandwidth; 
35 FIG. 5 is a How diagram of one embodiment of content 
transfer; and 

FIG. 6 is a state diagram of one embodiment of a process 
for playback of digital media with near-online storage sup- 
port. 

40 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 1 is a diagram of one embodiment of a media server 

45 environment, indicated generally at 10. Environment 10 
includes a media server 12 that has access to digital media 
assets stored in online storage 14. Online storage 14. for 
example, can be an array of hard disk drives. Media server 
12 can also access digital media assets stored in tertiary 

50 storage 16, such as a CD ROM jukebox or a tape drive 
system, which provides near-online storage for digital media 
assets. Media server 12 is connected to a plurality of clicni 
systems IS across a communication network. The commu- 
nication network can be supported by a variety of conncc- 

55 lion types such as a local area network, wide area network, 
and the Internet. 

In general, a user of a client system 18 can send a request 
to media server 12 across the communication network. The 
request can identify a digital media title that the user desires 

60 to playback on client system 18. Media server 12 responds 
by accessing the appropriate media asset from online storage 
14. If the media asset is not available in online storage 14, 
media server 12 can initiate an asset transfer from tertiary 
storage 16 to online storage 14. Once the media asset is 

65 available, media server 12 separates the asset into data 
packets and streams the data packets to client system IN. 
Client system 18 receives the data packets and uses a 
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decoder to process the data packets and playback the digital 
media data. Further, although not shown in FIG. 1, media 
server environment 10 also can provide real-time streaming 
of digital media where the source is live encoded and 
transmitted across the network to client systems. Thus, s 
rather than digital media data originating from a file stored 
on a storage device, the data originates from a live feed. The 
digital media is then often multicast to clients systems which 
each use decoders to process the data packets and playback 
the digital media data. 10 

In the embodiment of FIG. 1, media server 12 provides 
support for near-online storage in a streaming environment. 
Based upon user requests (such as clicking on the URL for 
a video), media server 12 will automatically load assets from 
tertiary storage 16 onto disk storage 14 and provide play- 
back. Media server 12 can also automatically purge less 15 
popular assets from the disk storage 14 to make room for 
those assets in demand. Thus, in this scheme, more popular 
assets will end up on disk storage 14, while less popular 
assets will remain in tertiary storage 16. Online disk storage 
14 can thereby act as a cache for a large number of assets 20 
stored in tertiary storage 16. There are many potential 
policies for determining what to keep on disk storage 14 
based, for example, upon: current time, current load, the 
desire to use resources for playback and the willingness to 
deny requests, and the desire to be responsive and the 2 5 
willingness to tolerate thrashing. 

With respect to tertiary storage 16 ? media server 12 is 
device independent. This allows media server 12 to interface 
with a variety of types of devices (e.g., CD jukeboxes, tape 
devices, DVDs, etc.) from a number of manufacturers, 30 
Generally, in addition to a file system interface, each manu- 
facturer offers special software for administering their 
devices and for moving content onto and out of their devices 
(e.g., APIs and tools). The device independence of media 
server 12 allows it to take advantage of any such special 35 
software to increase system performance. 

FIG. 2 is a flow chart of one embodiment of a process for 
near-online storage support. In step 20 of FIG. 2, a media 
server receives a request to play a digital media asset. In step 
24, the media server determines whether the asset needs to 40 
be loaded from tertiary storage. If not, the asset is played as 
normal for an online asset. If the asset does need to be loaded 
from tertiary storage, then a number of steps are performed. 
In step 26, storage space is allocated for placing the asset on 
online storage (e.g., disk storage). FIG. 3 illustrates one 45 
embodiment of this allocation of storage space. Further, 
allocation of storage may involve finding a victim asset on 
disk and purging that asset to make room for the newly 
loaded asset. The victim asset would then be left in the 
offline state. Loading from tertiary storage also comprises, in 50 
step 28, allocating disk bandwidth for the transfer of the 
asset. This can also involve the assignment of a service that 
will perform the physical transfer through a multi-resolver 
component. One embodiment of this allocation of band- 
width is shown, for example, in FIG. 4. 55 

To continue the load, in step 30, the media server physi- 
cally transfers the file or content of the asset front near- 
online storage to online storage (e.g., hard disk storage) 
using placement and disk bandwidth guarantees obtained in 
steps 26 and 28. FIG. 5 illustrates one embodiment of this 60 
content transfer. Then, in step 32, the media server performs 
asset finalization. This involves updating the asset state to 
indicate that the asset is now online. Further, VCR trick files 
and other data can be generated if necessary. One embodi- 
ment of asset finalization is also illustrated in FIG. 3. 65 

This near-online asset transfer scheme provides signifi- 
cant advantages to a media server system. The task of 
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physically transferring content, in step 30, can be left 10 
device -specific transfer processes that can exploit any fast- 
transfer capabilities, or other special capabilities, of the 
particular tertiary device. This allows many device specific 
transfer processes to be written and integrated into the media 
server. Using this architecture, for example, support can be 
successfully integrated for CD ROM jukeboxes manufac- 
tured by TRACER, LUMINEX, K-PAR, IXOS, EMASS, 
PIONEER and SONY as well as tape devices from EM ASS. 
Another advantage of this scheme is that the architecture 
along with the system primitive commands (load Asset and 
unloadAsset) can allow different policies to be employed in 
identifying victim assets on disk. The policy could be 
least-recently-played, least-frequently played, or others. The 
system architecture allows different policy schemes to be 
integrated for managing the cache of on-disk content. 

FIG. 3 is a flow diagram of one embodiment of allocating 
storage and asset finalization. This embodiment addresses, 
for example, a CD-ROM jukebox as the tertiary storage 
device. With respect to CD-ROM jukeboxes, each jukebox 
typically can contain a large number of CD-ROM devices 
(e.g., anywhere from fifty to several hundred) and a much 
smaller number of read-drives (e.g.. one to four). Also, there 
is often some kind of robotic interface that can move a 
CD-ROM from its slot into a read-drive. The access to 
CD-ROM resident files is then accomplished through a 
middle layer, provided by software vendors, such as K-PAR, 
LUMINEX, TRACER, etc. A common feature of all these 
packages is that there is a UNIX file -path access to any 
CD-ROM resident file. In other words, files and directories 
can be listed or read using regular UNIX calls and com- 
mands. The access software also usually includes adminis- 
tration and disk caching. In the embodiment of FIG. 3. a 
jukebox transfer service 40 keeps the state of the transfer and 
changes to the state of an affected asset so that the state is 
not lost in case of service crash or interruption (such as loss 
of electrical power). 

As shown in FIG. 3, jukebox transfer service (.IBTS) 4(1 
makes a request to load the requested asset to a content store 
application program interface (API) 42. This request 10 
content store API 42 effects a change of the asset state to 
"loading" and prevents the asset from being accidentally 
deleted or modified by another process. The state is updated 
in asset metadata held in a persistent object store (POS) 44. 
Persistent object store 44, for example, can comprise a 
persistent object in a database accessed through a database 
engine 46. Next, jukebox transfer service 40 makes a request 
to "run allocation phase." Ill is request is forwarded by 
content store API 42 to a storage manager 4S. Storage 
manager 48 is a component of the media server responsible 
for allocation of online disk storage and disk bandwidth. In 
this process, storage manager 4H allocates storage for place- 
ment of the asset on available file system disk storage 50. 
Then, jukebox transfer service 40 makes a request to physi- 
cally transfer the data from near-online storage to online 
storage. Following the physical transfer, jukebox transfer 
service 40 makes a request to "run finalize phase/ 1 In this 
phase, content store API 42 generates auxiliary files used for 
fast forward and rewind actions, trims any excess disk space 
as well as updates asset metadata in persistent object store 44 
to indicate that the asset is now available on online storage. 

FIG. 4 is a How diagram of one embodiment of allocating 
disk bandwidth. As shown, a proxy service 62 can receive 
and process a client request for assets and can invoke 
jukebox transfer service 40. In the embodiment of FIG. 4. 
requests to allocate disk bandwidth either for playback or 
recording are made through a common component, multi- 
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resolver 66. Muliiresolver 66 is responsible for contacting a can be unloaded which temporarily places it in an ''unioad- 

storage manager 68 to allocate disk bandwidth. Multire- uig" state 88 before it returns to the "available on backing 

solver 66 also contacts a connection manager (not shown) store*' state 84. 

for allocating network bandwidth, if necessary. Multire- Further, while in "loading" slate 86, playback of i he asset 

solver 66 further chooses a delivery service to perform the 5 can begin if there is enough data available to do so. Whi'.e 

playback or recording. Within the context of jukebox trans- m "available" state 82, the number of plays can be changed 

fer service 40, multiresolver 66 is invoked with an "import" which moves the asset temporarily to a "changing number of 

delivery specification. Multiresolver 66 responds by com- plays" slate 92. The number of plays can also be changed 

municating with storage manager 68 to allocate disk band- £ om lhe "available on backing store" state S4. From either 

width for recording. Multiresolver 66 also chooses a deliv- 1(J "available" state 82 or ''available on backing siorc" siaic 84. 

ery service to do the content transfer. In this case, the target lne asset can t, e deleted which moves it to a "being deleted" 

delivery service can be a remote delivery service (RDS) 70. state 90 ^f^ T lne deletion is complete, the asset "disap- 

Multiresolver 66 can also have an interface which allows a pears" from the system. 

requestor to pass delivery service -specific parameters such ^ shown in FIG. 6, playback of an asset can be permitted 

as passing the name of a pipe (FIFO) from which remote 15 wmie l{ j s i oa ding from the backing storage device (c.$. : 

delivery service 70 should read. The role of the pipe (FIFO) CD-ROM jukebox). This is quite useful for long assets that 

is described, for example, with respect to FIG. 5. are several hours in duration since they can take ;i long time 

FIG. 5 is a flow diagram of one embodiment of content l0 i oac j. By allowing playback to begin before the loud is 

transfer As shown, jukebox transfer service 40 invokes a complete, the client does not have to wait for the entire asset 

device specific jukebox copy program 72 and creates a pipe 2 o to load from the backing storage. The playback cm begin .is 

(FIFO) 76. Jukebox copy program 72 accesses a jukebox 74 soon as somc initial segment of data is transferred. Such 

and transfers content data from an appropriate CD ROM to playback of partially loaded asset can be permitted, for 

pipe 76. Jukebox transfer service 40 also provides the name example, only if the transfer rate of the asset from the 

of pipe 76 to remote delivery service 70. In the embodiment backing store device is higher than the playback rate (or data 

of FIG. 5, remote delivery service 70 knows how to read 2 s consumption rate) of the client. The amount of initial data 

from one file source and write to another, and a read from a that is required for allowing such playback (while asset 

named pipe 76 appears to remote delivery service 70 like a transfer is in progress) can be determined from the delivery 

read from a file. Remote delivery service 70 reads data from service requirements, which can require, for example. 5 1 2 

pipe 76 and writes the data to online disk storage 78. Disk kilobytes of data. 

storage 78 provides online storage for streaming the asset to 30 As mentioned above, each asset has a state indicating 

its destination. whether it is online or offline and can have an associated Hag 

In operation, jukebox transfer service 40 duplicates the ("can being playback") indicating whether enough bytes are 

write-end file descriptor of the pipe 76 to a "stdout" file available to permit playback while loading is in progress. As 

descriptor and forks/executes jukebox copy program 72. shown in FIG. 6, when an asset installation is initialed, the 

Jukebox copy program 72 operates to pump the data as fast 35 asset is in "being installed" state 80. For a non -backing store 

as possible from a CD-ROM resident file to stdout. Since asset, when the asset installation completes, the asset enters 

stdout is actually the write descriptor of the pipe 76, that is "available" state 82. This is the state in which an asset is 

where the data goes. When jukebox copy program 72 has normally available for playback. For backing store assets, 

written all the data to the stdout, which in fact is going into the asset is in "available on backing store" state 84 alter 

the write-end of pipe 76, it will simply exit. Shortly co installation. When a user attempts to play an asset from this 

thereafter, remote delivery service 70 will get an end-of-file state 84, a "loadAssct" primitive can be called placing the 

indication, will call mark that data as filled in, and will close asset in "loading" state 86. At this point, the device specific 

the reading-end of pipe 76. transfer program begins transferring data from the backing 

Since jukebox transfer service 74 started jukebox copy storage to online storage. As soon as "enough data" has been 
program 72, it will get a signal when jukebox copy program 45 transferred, the "can begin playback" flag can be set to 
72 has exited. This provides the indication that data transfer permit playbacks from that point forward. When the transfer 
completed. Note that there is no need for jukebox transfer is complete, the asset enters "available" state 82 as men- 
service 40 to poll remote delivery service 70, which is tioned above. At any point, to determine whether playback 
consistent with completing the transfer as fast as possible. At can be permitted on an asset, the following simple rule can 
the completion of data transfer, jukebox transfer service 72 50 be used: 

runs the finalization phase on the task. In response, content if (asse utaie~avaUabi c ||a S s C t.c a nBe 6 mPiayback--;m C ) f pem «i 

processors are invoked to generate auxiliary files at that playback;} 
point and mark asset as available. Upon completion of the 

finalization phase, the asset is available for playback and Once the data starts moving from the storage device to 
jukebox transfer service 40 can safely discard the transfer 55 disk storage, the media server can play it after a short, 
task as complete. administrator-configurable delay. An assumption can he 
FIG. 6 is a state diagram of one embodiment of a process for made that the average transfer rate from tertiary device 10 
playback of digital media with near-online storage support. disk storage will be faster than the playback rate. However. 
As shown, the installation of an asset on the system initially it is possible that, due to process contention, memory 
places it in a "being installed" stated 80. From this stale, the 60 swapping or other factors, the transfer rate may temporarily 
asset can be directly installed such that it is in an "available" fall below the playback rate. Therefore, capability is pro- 
state 82. Alternatively, a backing store of the asset can be vided for the administrator to specify a time buffer, i.e. delay, 
installed placing the asset in an "available on backing store" before the media server starts playing the asset. This delay 
state 84. In misstate, a load event temporarily changes the should be empirically based on the specific customer 
asset to a "loading" slate 86 while the asset is moved to 65 configuration, such as hardware, amount of disk and 
online storage. After completion of the transfer, lhe asset is memory, etc. It should generally be no more than about 
in "available" state 82. From "available" state 82, an asset fifteen seconds. In case the average transfer rate is less than 
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the playback rale, the asset can be loaded completely before such assets first need to be moved to disk storage before 

playing (i.e., as discussed above). being played back and can be paged out of disk storage by 

Further, an asset can have a number of higher level assets a purging algorithm. To install a tertiary storage backed 

denned on it. These can be referred to as derived assets. asset, (he media server scans the asset to perform sanity 

Examples of such assets include sequential assets and clip s checks and compute sizes for auxiliary files. Hie media 

assets. Such assets can also go through state transitions as server then creates metadata for the handle and the asset tree, 

described above when one of the underlying assets go offline and the path to the backing file is stored. The placement type 

or online. That is, when an underlying asset goes to the for the asset indicates that the asset is backed by tertiary 

"available on backing store" state, all of the higher level storage. 

assets defined on it also enter the "available on backing 10 After installation is complete, the user interface indicates 

store" state. Similarly, when an underlying asset enters the whether the tertiary storage backed asset is currently rcsi- 

"available" state from the "available on backing store" state, dent on disk storage or whether a delay to load the asset is 

then the higher level assets can enter the "available" state as required before playback can begin. This indication can l>c 

well if all other children of the higher level assets are in the accomplished, for example, either by rendering the asset 

"available" state. 15 name on the screen in a different format. 

According to the present invention, a media server can The transfer of a tertiary storage asset to disk storage, or 

implement support for device independent near-online stor- swap-in, can be initialed, for example, when a user clicks on 

age that treats varied types of tertiary storage devices an asset URL, and the asset is not on disk storage at thai 

uniformly and yet allows for exploitation of unique perfor- time. In one implementation, the request goes to a server 

mance characteristics of each type of tertiary storage. One 20 which responds with a document containing the handle 

core aspect of this asset management scheme is that it allows name, server name and other static details of the asset back 

an asset to have a permanent backing storage location from to the user's web browser. The browser then invokes a 

which the asset content can be loaded anytime, on demand. streamplayer application. The streamplayer makes a library 

The asset management scheme maintains state information call to the media server which determines whether the asset 

for each such asset to indicate whether it is online or offline. 25 is a tertiary storage backed asset and whether it is currently 

Further, a set of primitive commands are provided (e.g., on disk storage. If it is on disk storage, the regular playback 

loadAssei and unloadAsset) for state transition between process proceeds. If, however, the asset is not on disk 

these slates. The actual loading of an asset from a tertiary storage, a special parameter is provided to the si ream player 

storage device onto disk storage is split into a number of to indicate that the asset needs to be loaded, and the media 

phases: storage allocation, transfer, and asset finalizalion. 30 server initiates the process to transfer the asset to disk 

The transfer phase can use device specific transfer processes storage. 

that can exploit any specific fast-transfer characteristics of a In this implementation, the special parameter to the 

particular tertiary storage device. streamplayer indicates that the tertiary storage backed asset 

As discussed, the loading of assets can be device inde- is being transferred to disk and provides an estimate for the 

pendent in that the details of the middle layer that interfaces 35 time the transfer wall take. At that point, streamplayer 

to the tertiary storage can be handled by the particular device invokes a special count-down helper application, rather than 

implementor. However, in this layer, there are a number of the regular player. The streamplayer itself can then exit and 

helpful common features. One is that there be a UNIX free up the browser from which it was invoked. The count - 

file-path interface to any file on any device within the down application presents a small, separate browser window 

tertiary storage. Thus, any UNIX call or command thai takes *o with a clock ticking down. When the count-down reaches 

a file path should be able to transparently access tertiary zero, the application will send the video URL again to the 

storage resident files. Another feature is a command-line web server. At that point, the same processing as above is 

program that permits high-speed reading of data. This pro- repeated. If the asset happens to be on disk storage, the 

gram takes as parameters a fully-qualified file name, offset media server returns normal parameters, and the stream* 

and length. The program will than pipe the data as fast as 45 player will start up the player. If not, the media server needs 

possible from the file to stdout. The major goals of this are to detect that the transfer to disk storage had previously been 

to minimize latency in starling the transfer, to support many initiated and return back the current time estimate to 

simultaneous reads from multiple files, and to maximize the completion. This algorithm will also work if another user 

transfer rate. In addition, the command-line program, given requests the same asset while the first transfer request is still 

a file name, offset and length, returns estimates on lime to 50 in effect. It should be noted that with this implementation, 

start the transfer and time to complete the transfer. A further even once the asset is transferred to disk storage, the user 

helpful feature is a command-fine program that relums who initiated the transfer is not guaranteed to be able to piay 

on-line/off-line status for a particular file. In other words, if it. The play could fail for a number of reasons, such as disk 

the device on which the file is resident is in the tertiary storage or network bandwidth not available or the appropri- 

storage and enabled, the command will return that the file is 55 ate player not installed. 

on-line. Additionally, an HTML-based administration and As discussed above, there can be a special transfer service 

configuration interface is a helpful to allow the media server operating on the media server to effect transfer of the asset 

to have a URL link to the appropriate configuration screens. to disk storage. In one case, the media server has a jukebox 

Default versions of these programs can be implemented in transfer service (JBTS) whose responsibility is 10 handle 

case a particular tertiary storage does not support the above 60 transfers from a CD-ROM jukebox to disk storage. Also as 

features, but the performance and accuracy of default pro- discussed above, tertiary storage backed assets that had 

grams may be worse than what could be achieved if an previously been transferred to disk storage can be purged m 

implementor writes them itself. make room for new assets being transferred. In this scheme. 

Using the present system, a system administrator can both tertiary storage backed and regular assets can he mixed 

install assets resident in tertiary storage resident and indicate 65 on same file systems managed by the media server but only 

to the media server that the asset is backed by tertiary tertiary storage backed assets can be purged to make room 

storage. Tertiary storage backed assets are different in that for another tertiary storage backed asset. 
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On the above media server, ihe storage manager maintains 
data on asset usage, such as popularity (frequency of 
playouts) and least-recent usage, in order to implement 
cache management. When a call is made to load a tertiary 
storage resident asset, as a result of the allocation phase, the 5 
storage manager finds space for the asset using a cache 
management scheme. If there is no space available, the 
storage manager chooses a tertiary storage backed asset to 
be purged. If no such asset can be found, the storage 
manager returns a "space unavailable" error aud the alloca- 
lion phase call fails. 

When playing a partially installed asset, the media server 
needs to decide at what point to start playback of a partially 
installed asset or whether to wait until the asset is fully 
installed. In one embodiment, this is based on the configured ^ 
playback delay, D, the playback rate, P, and the amount of 
data, A, that has been transferred and the transfer rate, T. In 
this scheme, if P>T, the media server should wait until the 
asset: is fully installed. Otherwise, the media server should 
wait for the condition: A/P>=D before initiating play back. ^ Q 

Although the present invention has been described in 
detail, it should be understood that various changes, substi- 
tutions and alterations can be made thereto without depart- 
ing from the spirit and scope of the invention as defined by 
the appended claims. 25 

What is claimed is: 

1. A media server system having online storage storing a 
plurality of media assets, tertiary storage storing a plurality 
of media assets on tertiary storage devices to provide 
near-online storage, a media server having access to the 3Q 
online storage and the tertiary storage, the media server 
operating to receive a user request for a media asset, 
determine whether the requested media asset needs to be 
loaded from the tertiary storage, if so, to allocate storage 
space in the online storage for the requested media asset 35 
before transferring content specific to the tertiary storage 
devices to transfer content of the requested media asset to 
the online storage, the media server system comprising: 
a storage manager that allocates bandwidth on the online 
storage for transfer of the requested media asset from CQ 
tertiary storage to online storage, wherein bandwidth 
allocation comprises allocation for timing-dependent 
applications including a video content delivery appli- 
cations timing requirement; 
an application program interface, the application program 45 
interface including a UNIX file path interface that 
accesses media assets stored on the tertiary storage 
devices independent of vendor specific device drivers: 
a plurality of transfer services specific to the tertiary 
storage devices that transfer the requested media asset 50 
to the application program interface; 
state information associated with the requested media 
asset the state information protecting the integrity of 
the requested media asset by indicating that the 
requested media asset is being transferred and prevent- 55 
ing the modification or deletion of the requested media 
asset, the state information also indicating that the 
requested media asset is online once it has been trans- 
ferred from tertiary storage to online storage; and 
a pipe data structure created by the transfer service of the 60 
tertiary device for transferring content from tertiary 
storage to online storage, the pipe comprising a first in 
first out queue that has a read end and a write end, the 
pipe data structure providing a way to use either the 
device independent application program interface or 65 
one of the device-specific plurality of transfer services 
to perform the transfer. 
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2. A media server system according to claim 1, wherein 
said online storage comprises hard disk storage. 

3. A media server system according to claim 1, wherein 
said tertiary storage devices comprise magnetic tape 
devices. 

4. A media server system according to claim 1. wherein 
said allocating storage space comprises finding a victim 
media asset and purging the victim media asset. 

5. A media server system according to claim 4, wherein 
said allocating space further comprises setting a .state- of die 
victim media asset to an offline state. 

6. A media server system according to claim 4. whcicin 
said victim asset comprises a least recently loaded media 
asset having backup storage in said tertiary storage. 

7. A media server system according to claim 4. wherein 
said victim asset comprises a least frequently requested 
media asset having backup storage in said tertiary storage. 

8. A media server system according to claim I, wherein 
said tertiary storage devices comprise CD-ROM devices and 
said tertiary storage comprises a CD-ROM jukebox. 

9. A media server system having online storage storing a 
plurality of media assets, tertiary storage storing a plurality 
of media assets on tertiary storage devices to provide 
near-online storage, a media server having access ;o the 
online storage and the tertiary storage, the media serve r 
operating to receive a user request for a media asset, 
determine whether the requested media asset needs to be 
loaded from the tertiary storage, if so, to allocate sioragc 
space in the online storage for the requested media asset 
before transferring content specific to the tertiary storage 
devices to transfer content of the requested media asset to 
the online storage, the media server system comprising: 

a storage manager that allocates bandwidth on the online 
storage for transfer of the requested media asset from 
tertiary storage to online storage, wherein bandwidth 
allocation comprises allocation for timing -de pendent 
applications including a video content delivery appli- 
cations liming requirement; 

an application program interface, the application program 
including a UNIX file path interface that access media 
assets stored on the tertiary storage devices hide pen- 
dent of vendor specific device drivers; 

a plurality of transfer services specific to the tertiary 
storage devices that transfer the requested media asset 
to i he application program interface; 

state information associated with the requested media 
asset, the state information protecting the integrity of 
the requested media asset by indicating that the 
requested media asset is being transferred and prevent- 
ing the modification of deletion of the requested media 
asset, the state information also indicating that the 
requested media asset is online once it has been trans- 
ferred from tertiary storage to online storage; 

a pipe data structure created by the transfer service of the 
tertiary device for transferring content from tertiary 
storage to online storage, the pipe comprising a lirsi in 
first out queue that has a read end and a write end, the 
pipe data structure providing a way to use cither the 
device independent application program interface or 
onc of the device-specific plurality of transfers services 
to perform the transfer, 

the online storage comprises hard disc storage and the 
media server further operates to allocate disk band- 
width in the online storage prior to transferring content 
and to perform asset finalization for the requested 
media asset after transfer of the content, the assei 
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finalization comprises updating a stale of the requested 
media asset to an online state; 

the transfer process is specific to a vendor of the tertiary 
storage device; and 

allocating space compromises finding a victim media 5 
asset and purging the victim media asset and setting a 
state of the victim media asset to and offline state, and 
the victim asset comprises a least recently loaded media 
asset having backup storage in the tertiary storage. 

10. A media server system according to claim 9, wherein 10 
said online storage comprises hard disk storage. 

11. A media server system according to claim 9, wherein 
said tertiary storage devices comprise magnetic tape 
devices. 

12. A media server system having online storage storing 15 
a plurality of media assets, tertiary storage storing a plurality 

of media assets on tertiary storage devices to provide 
near-online storage, a media server having access to the 
online storage end the tertiary storage, the media server 
operating to receive a user request for a media asset deter- 
mine whether the requested media asset needs to be loaded 
from the tertiary storage, if so, to allocate storage space in 
the online storage for the requested media asset before 
transferring content specific to the tertiary storage devices to 
transfer content of the requested media asset to the online 25 
storage, the media server system comprising: 

a storage manager that allocates bandwidth on the online 
storage for transfer of the requested media asset from 
tertiary storage to online storage, wherein bandwidth 30 
allocation comprises allocation for timing-dependent 
applications including a video content delivery appli- 
cations timing requirement; 
an application program interface, the application program 
interface including a UNIX file path interface that 35 
accesses media assets stored on the tertiary storage 
devices independent of vendor specific device drivers; 
a plurality of transfer services specific to the tertiary 
storage devices that transfer the requested media asset 
to the application program interface; 



state information associated with the requested media 
asset, the slate information protecting the integrity of 
the requested media asset by indicating that the 
requested media asset is being transferred and prevent- 
ing the modification or deletion of the requested media 
asset, the state information also indicating ihnt i lie 
requested media asset is online once it has been trans- 
ferred from tertiary storage to online storage; 

a pipe data structure created by the transfer service of the 
tertiary device for transferring content from tertiary 
storage to online storage, the pipe comprising a first in 
first out queue that has a read end and a write end, the 
pipe data structure providing a way to use either ihc 
device independent application program interface or 
one of the device-specific plurality of transfer services 
to perform the transfer; 

the online storage comprises hard disk storage and i lie 
media server further operates to allocate disk band- 
width in the online storage prior to traasferring content 
and to perform asset finalization for the requested 
media asset after transfer of the content, the asset 
finalization comprises updating a state of the requested 
media asset to an online state; 

the transfer process is specific to a vendor of ilic tertian 
device; and 

allocating space comprises finding a victim media a.ssct 
and purging the victim media asset and setting a state 
of the victim media asset to an offline state, and ihc 
victim asset comprises a least frequently requested 
media asset having backup storage in the tertiary stor- 
age. 

13. A media server system according to claim 12, wherein 
said online storage comprises hard disk storage. 

14. A media server system according to claim 12. wherein 
said tertiary storage devices comprise magnetic taps devices. 
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